Conventionally, an information processing apparatus has to be equipped with software including basic functions of an operating system (OS) such as a kernel, to execute an application prepared by a user (hereinafter, “user application”). The kernel includes various main functions such as monitoring user application(s) and/or peripheral devices, managing resources such as disks and memories, interrupt processing, inter-process communications, etc.
A group of given operations executed by the information processing apparatus described above is generally called a process, and several processes are executed in series or in parallel under the control of the kernel. During the execution of a process, the kernel continuously monitors details concerning the execution of the process and aborts the process if a given event such as an interrupt and an error occurs.
The abort is described with reference to FIGS. 10 and 11. FIG. 10 is a flowchart of an abort signal transmission process executed by the kernel. FIG. 11 is a flowchart of an abort signal reception process executed by the application.
As depicted in the flowchart of FIG. 10, the kernel determines whether an event causing an abort has occurred (step S1001). The kernel awaits the occurrence of an event (step S1001: NO), and upon the occurrence of an event (step S1001: YES), executes an abort signal transmission process (step S1002). Then a signal transmission operation is executed (step S1003), and the operations of the kernel end.
The application, on the other hand, determines whether a signal from the kernel has been delivered (step S1101). The application awaits delivery of the signal (step S1101: NO). Upon delivery of the signal (step S1101: YES), a signal reception operation is executed (step S1102). Then, the application executes a reception process related to abort (step S1103). Through the procedure described above, the operations of the application end (see, for example, Japanese Patent No. 2836683).
As described in FIGS. 10 and 11, the abort signal is sent via the kernel. However, information concerning the sender of the signal (here, the kernel) is not communicated to the process of the recipient of the signal (here, the application). Furthermore, the executor of the process that has received the signal (here, the user of the information processing apparatus) does not have any means to search for the information concerning the sender of the received signal.
For example, in Solaris (a typical UNIX-like OS), information passed on to the signal reception operation during the signal transmission operation is limited to the following 4 items: (1) pointer information concerning the reception process; (2) pointer information concerning the receiving kernel thread; (3) information concerning the signal number; and (4) flag information indicating whether the source of the signal is the user or the kernel.
As a means to collect information concerning the sender of the signal, Solaris can be equipped with Audit (audit) and/or DTrace (dynamic trace) for use in the signal transmission operation (step S1003) described in FIG. 10. However, these two functions are set on the assumption that the same problem will occur again. Thus, if the problem does not reoccur, no information for investigation can be collected. Further, setting the functions requires some skill.
Furthermore, the impact of Audit and/or DTrace on system performance should be considered. In particular, Audit is likely to increase the load on the system since Audit obtains all information of a specified pointer. Furthermore, the information that can be collected by Audit and/or DTrace is for the entire system and for a system manager. Thus, even if a user executing the aborted process obtains the information, it is difficult for the user to investigate the cause of the abort. In other words, it is difficult for ordinary users to identify the cause of the abort.
Nonetheless, there are many cases in which a process is aborted due to reception of an unexpected signal, and thus the sender of the signal causing the abort needs to be investigated. However, the cause cannot be investigated due to the absence of the information concerning the sender of the signal. Currently, the user has no countermeasure other than setting Audit and waiting for a reoccurrence of the problem. As a result, in many cases the cause remains unidentified.